Functional data includes electronic data that can be used to, among other things, establish or verify an identity, access a data system or account, or otherwise enable functionality in a digital environment. We all live with functional data. We typically invoke myriad functional data elements on a daily basis to sustain and enrich our lives.
An important aspect of the functional data landscape is identity. Character-based identity elements such as name, birth date, social security number and street address are powerful elements of functional data. A drivers' license—with a number of its own—may entitle one to cast a vote, drive a car on a public road or purchase a bottle of wine.
The personal signature is an equally powerful image-based identity element. But—some special categories of transactions aside—the personal signature has been largely replaced by the digital persona. Proving your identity in the digital world involves its very own dimension of functional data, from usernames and passwords to PIN codes to security questions to any number of trivial details that can help to prove you are who you say you are.
With proof of identity, countless other dimensions of functional data become accessible. For example, a credit card number can be used to purchase a staggering variety of products. A bank account identifier or investment account number is generally required to access financial resources. An email address or phone number enables personal communication with other people all around the world. Under certain circumstances—particularly if one's identity has been compromised—any one of these functional data elements can be abused without the knowledge or express consent of their “owner.”
In the digital world, protecting functional data has become very complicated. We regularly create lasting records of various functional data elements across countless digital systems and networks. Despite the best of intentions (in most cases) and the most advanced technologies, these systems and networks are increasingly vulnerable. If perpetrators can amass a sufficient number of functional data elements to convincingly portray your digital persona, they can invoke those elements to exploit your resources for their gain.
But we must share our functional data nonetheless, to invoke it for our own gain. In sharing it, we may authorize others to invoke it for a particular electronic transaction or transactions. Sometimes we do so as a matter of personal trust—such as sharing a credit card number with a spouse, a child, or an assistant, to invoke it for our benefit and/or for theirs. Other times we do so as a matter of commercial necessity—such as answering a series of personal questions for a customer service representative, handing a credit card to a waiter, or completing an online form for a trusted retailer.
The challenge is to somehow control propagation of authorization to use our functional data elements, and further to limit the scope for the use of our functional data elements in the digital world.
The inventive methods and systems described herein, while spanning a wide array of applications, leverage the same general concept, dubbed “Encapsulated Security Tokens” (“ESTs”). “ESTs” address the challenge of protecting functional data elements by requiring that any entity presenting such an element prove how they came to possess it. In certain implementations, legitimate possession is proven by an entity presenting, along with the functional data element itself, an EST that encodes the chain of propagation for that functional data element using a series of nested digital signatures. The functional data element can then be used in a digital transaction. As will be understood from the description below, such a digital transaction is not limited to financial transactions but encompasses all the ways that functional data may be used in a digital environment that involve transfer of data between parties.
The data components of this solution may include, within two or more nested iterations of digital signatures: 1) the functional data elements being secured, invoked, propagated, or otherwise used; 2) identifiers for the people or entities for whom the functional data elements are being authorized; 3) any conditions (optional) limiting use of the functional data elements by the people or entities for whom the functional data elements are being authorized; and 4) tagging on the signed object and associated data inclusions in subsequent iterations, enabling validation of the digital signature and thus authentication of the signed content.
The processing of this data may involve 1) a secure cryptographic system, applied with each nested iteration to one or more of i) the functional data elements, at least in part, ii) the identifier for the person or entity for whom the elements are being authorized, iii) any conditions limiting use of the elements, and iv) a signed object from a prior iteration (for all but the very first iteration); 2) a feedback mechanism at each iteration, which enables a functional data owner or custodian to actively track, model and manage the proliferation of its “data propagation tree”; and 3) an objective, such as preventing an unauthorized login, stopping unwanted spam, ensuring the integrity of a vote, or protecting a bank account. The cryptographic system, and in particular a digital signature system facilitated by the cryptographic system, provides value by encoding distinct events in the propagation of authorization to use functional data elements, essentially proving, for each of those events, that the owner or custodian of those functional data elements has personally granted rights with respect to those elements to another person or entity with the conditions specified. In general, there will also be an entity or entities managing or enforcing an EST policy to ensure the objective is met. Such management or enforcement may be executed by an application, an email provider, a voting aggregator, a bank or another party depending on the transaction context.
In certain applications and scenarios, the present invention involves multiple, nested digital signatures encoding successive propagation events. The point of multiple iterations is not merely to propagate authorization but rather to produce a single object that can be invoked to secure a future transaction process. The effect of multiple iterations is to join distinct datasets and distinct digital signatures through at least two events, where each successive event reaffirms all prior events. Consequently the functional data contained in the innermost signed object becomes incrementally more secure as conditions and digital signatures are added with each propagation event, producing an object that is very narrowly applicable and much more difficult to counterfeit.
In accordance with one aspect of the present invention, a method and apparatus (“utility”) is provided for creating an EST. The utility involves obtaining first digital data from a first party of a prospective digital transaction. For example, the digital data may include functional data such as personal identification information, financial information or contact information. A processing system, such as one or more computers controlled by one or more entities, can then be used to generate the EST by encapsulating at least the first digital data using at least first and second cryptographic systems. In this regard, each of the cryptographic systems includes a signature and a signature verification. For example, a public key/private key system may be used for each of the cryptographic systems. The EST can then be made available to a party for use in a digital transaction. That party (the second party) may be the same as or different than the first party depending on the transaction context.
As noted above, the digital data is encapsulated at least twice using cryptographic systems to form an EST. In some cases, the digital data will be encapsulated many times as the functional data elements are propagated across a chain of custody. The security of the digital data is enhanced as the digital data is successively encapsulated because additional cryptographic systems are involved at each successive layer of encapsulation, thus further confounding any attempted fraudster. Preferably, each of the cryptographic systems utilized is an independent system so as to further reduce or substantially eliminate the possibility of unauthorized encapsulation. The successive layers of encapsulation also encode a chain of propagation that is useful for tracing the chain of propagation back to the original source, for auditing of appropriate propagation, and for termination or modifying the rights of any party or parties, among other things.
In the case of public/private key systems, encapsulation at each layer will generally be accomplished by digitally signing the digital data, and any other data included in the core or added thereto, using the private key furnished by a cryptographic system to the person/entity applying the signature. One exception to this, as will be clarified by the examples below, is that one layer of encapsulation may be accomplished using a public key for encryption in situations where the EST is presented for de-encapsulation to the party holding the private key mated to the public key. This may be thought of as a reflective case as the encapsulation is executed at least in part under the control of the party to whom the EST is presented for de-encapsulation. In any event, de-encapsulation in a public key/private key system involves a mirror image application of mated key pairs such that a digital signature is required in connection with at least one layer of encapsulation thereby ensuring security of propagation for the functional data elements.
The nature of the digital data and process for encapsulating that data can vary depending on the transaction context. For example, in cases where the electronic transaction involves a first party authorizing a second party to act on its behalf (e.g., an electronic power of attorney), the digital data may identify the first and second parties and a scope of authority granted, and at least the initial encapsulation may be executed under the control of the first party. Similarly, where the digital transaction involves allowing the second party to access an asset of the first party (such as a financial account, an email account or a phone number) the digital data may identify the asset and the second party, and at least one layer of encapsulation may be executed under control of the first party. As a further example, in the case where the digital transaction involves accessing an application (or other limited access resource), the digital data may include login credentials provided by a user and the initial encapsulation may be executed under the control of the application operator. It will be appreciated from the description below that many other scenarios are possible, particularly where functional data is propagated across a chain of multiple custodians. In such cases, the digital data may itself comprise, at least in part, an EST.
In accordance with another aspect of the present invention, a utility is provided for presenting or using an EST. The utility involves providing first digital data for use in generating and encapsulating an EST. Again, such digital data may include personal identification information, account information, contact information or other functional data. The utility further involves obtaining an EST where the EST is generated by encapsulating at least the first digital data using at least first and second cryptographic systems. Each of the cryptographic systems includes a digital signature and a signature verification. Presentation is accomplished by electronically presenting, in connection with a digital transaction, the EST together with functional data for the digital transaction. In this manner, the presenter can establish legitimate possession of the functional data including how the presenter came into possession of the functional data.
In accordance with a still further aspect of the present invention, a utility is provided for using a presented EST to authenticate the rights of the presenter of the EST to invoke functional data. The utility involves receiving functional data for a proposed transaction and an EST from a first user. Again, the EST has been generated by encapsulating at least first digital data using at least first and second cryptographic systems. The EST is then de-encapsulated to obtain the first digital data or a transformation thereof. The presented functional data or an equivalent transformation thereof can then be compared to the de-encapsulated first digital data to control the proposed digital transaction. In this regard, the de-encapsulated first digital data may include information verifying legitimate possession of the functional data. In a preferred implementation, at least an element of the encapsulated first digital data is identical to the corresponding presented element of the functional data so as to allow for ready comparison and provide self-executing functionality.
In accordance with a further aspect of the present invention, a utility is provided for use in propagating authority to use functional data in connection with a digital transaction. The utility involves receiving the first digital data including at least functional data. The digital data may include additional information, for example, defining a scope of authority conveyed in relation to the functional data or limitations thereon. The utility further involves adding, to the digital data, information sufficient to identify an authorized party. An EST is then generated by encapsulating at least the first digital data and authorization data using at least first and second cryptographic systems. The EST can then be propagated to the authorized party. It will be appreciated that this process can be repeated multiple times across a chain of propagation resulting in a multiply-encapsulated data object. Data representing the chain of propagation encoded in the EST can be stored along with data from other ESTs, and used to track functional data propagation and to manage a propagation tree, e.g., by modifying or terminating rights with respect to a selected branch, sub-branch or the like.
In accordance with a still further aspect of the present invention, a method is provided for generating a multiply-encapsulated data object for securing functional data. The utility involves establishing a once-encapsulated data object by encapsulating at least one or more elements of functional data using a first cryptographic system. A multiply-encapsulated data object is then established by encapsulating at least the once-encapsulated data object using a plurality of further cryptographic systems. Each of the cryptographic systems includes a digital signature (generally used for encapsulating data) and a signature verification (generally used for de-encapsulating the data). Preferably, each of the cryptographic systems are independent systems. In this manner, counterfeiting and using the data object would require misappropriation of digital signatures from multiple sources. It will thus be appreciated that, unlike conventional systems, security is enhanced as the functional data is propagated across multiple parties in a chain of propagation and a series of digital signatures are applied to the object.